1. Field of the Invention
The preferred embodiments of the present invention are generally related to increasing computer performance in the realm of software to hardware communications. More particularly, the preferred embodiments of the present invention are directed to a communication technique between software and hardware devices that informs downstream hardware devices that information is available in the system main memory with bounded latency.
2. Background of the Invention
In terms of availability and access to data in main memory, computer systems can be broken up into portions within the coherency domain, and portions outside the coherency domain. Some exemplary computer system components that would typically be within the coherency domain are microprocessor caches and the main memory. In a single microprocessor system, the difficulty of maintaining coherency of the microprocessor cache against main memory is relatively simple. Simplicity fades quickly however as multiple microprocessors are included in the computer system. Generally speaking, the cache of each microprocessor and the main memory array are kept coherent by the use of some form of cache coherency protocol, and the devices are thus within the same coherency domain.
As frequently happens in a computer system, software executed on one of the microprocessors needs to communicate command lists, data, or both to a downstream hardware device, most likely an input/output device such as a network interface card. In the related art devices, the exchange of command lists and/or data generally takes place by software executed within a microprocessor writing the commands and/or data to a first-in/first-out (FIFO) buffer in main memory. Once all or a significant portion of the commands and/or data have been placed in the FIFO buffer, the software sends a ready signal, also known as a doorbell, to the downstream hardware device indicating that the commands and/or data are available. Once the notification or doorbell has been received, the hardware device arbitrates for mastership of its associated bus, and reads the data from the buffer in main memory through known direct memory access techniques. In this way, the software is free to perform other steps, or the microprocessor may preempt that thread and execute other software threads, while the hardware device reads the commands and/or data, and executes the necessary steps. However, trends in software programming techniques inject the possibility of significant latency between placing of the commands and/or data in the FIFO buffer, and the doorbell notification arriving at the hardware device.
The standard paradigm in software to hardware communications over the last several years comprises one or more layers of abstraction between the software and the actual hardware device. That is, rather than the software having the capability of writing or communicating directly with the hardware device, software communicates with hardware through a driver program. Thus, it is the driver program or software that is responsible for protocol translations, handshaking, and the like, to move the commands and/or data from the software thread to the hardware. The advantage of this layer of abstraction from the programming point of view is that the software need only communicate with the appropriate driver, and hardware specific protocols and procedures are not a concern of the higher level program. Of course, the driver software, again just another program executed on the microprocessor, is still responsible for the communication process, including writing to the FIFO buffer and ringing the hardware doorbell as described above.
Recently, however, the trend has been to write software programs in “user-mode.” In user-mode, communications between the software and hardware may take place without levels of abstraction, or may take place with one or more levels of abstraction using drivers in a non-prioritized (non-kernel) mode. Regardless of whether the user-mode software communicates directly with the hardware device, or through a level of abstraction being a driver for that hardware device, software makes the communication. Although any piece of software is susceptible to preemption in today's computer systems, non-kernel software is especially vulnerable to such preemption. By preemption it is meant that for reasons beyond control of the software stream, execution is stopped for a time so that other processes and procedures may take place. These interruptions may be attributable to interrupts directed to the microprocessor, but may also be preemption to execute software streams with higher priority. Regardless of the reason, preemption at the wrong time, with regard to the software-to-hardware communication, has the potential for creating unbounded latencies between placing commands and/or data, and notifying the hardware.
Consider a related art communication from software executed on a microprocessor to a hardware device by way of a FIFO buffer in main memory. Further consider that the software has the opportunity to write the commands and/or data into the FIFO, but before the software can ring the hardware doorbell (send the message across one or more bridge devices and expansion buses), the software is preempted for an extended period of time. In this situation, the commands and/or data are loaded, but the hardware has yet to act because it has not received notification.
Preemption between the loading of the FIFO and the ringing of the hardware doorbell is possible whether the program is a user-mode program, an abstracted level of user-mode communication, or even a kernel mode driver. Inopportune preemption, however, is more prevalent in the user-mode and abstracted user-mode communications.
Thus, what is needed in the art is a more efficient way to notify hardware that commands and/or data are available in the buffer that facilitates communication between the software running on a microprocessor in the coherent memory domain and the hardware.